\section{Conclusão}

Este trabalho provou que existem soluções que permitem um acesso concorrente aos serviços da API JDBC, nomeadamente para acesso ao ResultSet. As soluções encontradas não só fornecem um mecanismo que garante um estado correcto do ResultSet num ambiente com múltiplos threads, como reduz a utilização e desperdício de recursos no cliente e no servidor.

O desempenho das soluções construídas a pensar numa execução concorrente superou o desempenho da solução que cria um result set para cada entidade concorrente (thread).

Face aos resultados de $CJDBC_S$, $CJDBC_I$ e $WJDBC$ conclui-se que se houver memória disponível no cliente para conter todo o result set, deve-se utilizar a solução $CJDBC_S$, diminuindo assim a quantidade de tráfego de rede e diminuindo também a dependência sobre os cursores do servidor, que se sabe serem menos eficientes do que utilizar um result set sem cursor \cite{CursorImplementations,PTUNCURSOR}. Caso não seja possível guardar na memória do cliente todo o result set, a escolha da solução recai para o $WJDBC$ se se pretender o máximo de desempenho. Porém, a solução $CJDBC_I$ também garante um desempenho superior a $JDBC$.

Se tivermos em conta os resultados do benchmark que simula alguma actividade entre operações sobre o ResultSet, então conclui-se que a solução $WJDBC$ deve ser evitada pois o seu desempenho sofreu um decréscimo enorme, apresentando um desempenho pior do que $JDBC$.
